CSDV3017  ·  DEVOPS  ·  SCHOOL OF COMPUTER SCIENCE, UPES

DevOps Principles,
Version Control & CI

Lecture 10 — the core principles that drive DevOps, how Version Control underpins every pipeline, and a first look at automating CI with GitHub Actions.

InstructorDr. Mohsin Furkh Dar
SessionWeek 4 · Mon, 29 Jun 2026
Time14:00 – 15:00
UnitUnit IV
I
II
III
IV
V
VI
VII
WHERE WE LEFT OFF

Recap & today's agenda

Lecture 9 · Done

Resilience Process

  • The four-stage loop: Detect → Alert → Respond → Refine
  • Key metrics: MTTD, MTTA, MTTR, MTBF
  • How the loop ties back to Kaizen and continuous improvement
  • Common pitfalls in incident response
Lecture 10 · Today

Principles, VCS & CI

  • The core DevOps principles that guide every decision
  • Version Control: SVN → Git → GitHub
  • Gitflow — the branching workflow used in industry
  • CI with GitHub Actions — automating builds & tests
FOUNDATIONS

The Core DevOps Principles

Principle 01

Systems Thinking

Optimize the entire value stream from code commit to customer, not just individual silos. A local optimization (e.g., "Dev ships faster") that hurts the whole system (Ops drowns) is a net loss.

Principle 02

Amplify Feedback Loops

The faster problems are detected and communicated back, the faster they're fixed. Short feedback loops — automated tests, monitoring alerts, code reviews — shrink MTTR and prevent escalation.

Principle 03

Continuous Experimentation & Learning

Take risks, fail fast, learn faster. Blameless postmortems, A/B testing, and canary deployments let teams experiment safely without fear of punishment for failure.

Principle 04

Automate Everything Repeatable

If a human does a task more than twice, automate it. Manual steps are slow, error-prone, and non-reproducible. Automation creates speed, consistency, and an auditable trail.

THE BACKBONE

Why Version Control is non-negotiable

"If your code isn't in version control, it doesn't exist. If your infrastructure isn't in version control, it's a ticking time bomb." — DevOps axiom

History

Time Machine

Every change is recorded with who, when, and why. You can always go back to any point in the past.

Collaboration

Team Safety Net

Multiple people work on the same codebase simultaneously. Branching and merging prevent them from overwriting each other's work.

Automation

CI/CD Trigger

Every modern CI/CD pipeline starts with a VCS event: "a developer pushed code." Without VCS, there is no automation.

EVOLUTION

SVN → Git: centralized vs distributed

Aspect Subversion (SVN) Git
Architecture Centralized — single server holds the only true copy. Distributed — every clone is a full repository.
Offline Work Impossible — need server for commit, log, diff. Full offline capability; commit, branch, log locally.
Branching Expensive directory copies; merging is painful. Lightweight pointer (~40 bytes); merge is a core feature.
Speed Network-bound for most operations. Local-first; nearly instant for most operations.
SPOF Risk Server goes down → entire team blocked. No single point of failure; any clone can restore.
Industry Legacy; still in some enterprises. Dominant; used by 90%+ of software teams.
GIT ECOSYSTEM

Git ≠ GitHub

Git (the tool)

Local Version Control Engine

  • Open-source, created by Linus Torvalds in 2005
  • Runs entirely on your machine (CLI: git init, git commit)
  • Tracks changes, enables branching, manages history
  • Knows nothing about pull requests, issues, or CI
GitHub (the platform)

Cloud Collaboration Layer

  • Web platform that hosts Git repositories remotely
  • Adds Pull Requests (code reviews), Issues (task tracking)
  • GitHub Actions — built-in CI/CD automation engine
  • Alternatives: GitLab, Bitbucket, Azure DevOps Repos

Think of Git as the engine and GitHub as the car body, dashboard, and GPS built around it.

BRANCHING STRATEGY

Gitflow — the industry-standard workflow

Gitflow defines a strict branching model with designated roles for each branch. It was introduced by Vincent Driessen in 2010 and remains widely used in enterprise DevOps.

Long-Lived Branches

main & develop

  • main — always reflects production-ready state; every commit is a release
  • develop — integration branch where features merge before release
  • Both are protected; no one commits directly to them
Short-Lived Branches

feature, release, hotfix

  • feature/* — branched from develop; one per task/user story
  • release/* — branched from develop for final QA before merging to main
  • hotfix/* — emergency patches branched directly from main
GITFLOW IN ACTION

The Gitflow lifecycle

Feature Development Lifecycle

From idea to production in 6 steps

develop
feature/*
develop
release/*
main
TAG v1.0
  • Step 1: Developer creates feature/login-page from develop
  • Step 2: Writes code, commits, pushes to GitHub, opens a Pull Request
  • Step 3: Code review + CI tests pass → merge into develop
  • Step 4: When sprint ends, create release/v1.0 from develop
  • Step 5: QA tests on the release branch → merge into main
  • Step 6: Tag the commit on main as v1.0 → deploy to production
EMERGENCY PATH

Hotfix — when production is on fire

The Scenario

Critical bug in production

A security vulnerability is discovered in main. The develop branch has 3 half-finished features that are not ready to ship. You cannot wait for the next release cycle.

The Hotfix Path

Bypass the normal flow

  • Branch hotfix/security-patch directly from main
  • Fix the bug, write a test, open a Pull Request
  • Merge into both main AND develop
  • Tag main as v1.0.1 and deploy immediately

The dual merge is critical: if you only merge into main, the next release from develop will reintroduce the bug.

CONTINUOUS INTEGRATION

CI — the heartbeat of DevOps

Definition

What is Continuous Integration?

Continuous Integration is the practice of automatically building and testing every code change the moment it is pushed to the shared repository. The goal: detect bugs within minutes, not days.

Step 1

Push

Developer pushes code to a branch on GitHub.

Step 2

Build & Test

A CI server automatically compiles the code and runs all unit/integration tests.

Step 3

Feedback

If tests pass → green checkmark. If tests fail → the PR is blocked and the developer is notified.

GITHUB ACTIONS

CI with GitHub Actions

What is it?

Built-in CI/CD Engine

  • Native to GitHub — no separate Jenkins server needed
  • Defined as YAML files in .github/workflows/
  • Triggered by events: push, pull_request, schedule, manual
  • Runs on GitHub-hosted Linux/macOS/Windows runners
  • Free tier: 2,000 minutes/month for public repos
Core Concepts

Workflow → Job → Step

  • Workflow: A YAML file defining the entire automation
  • Job: A unit of work that runs on a single runner (VM)
  • Step: An individual command or action inside a job
  • Action: A reusable plugin (e.g., actions/checkout@v4)
HANDS-ON

A real CI workflow file

# .github/workflows/ci.yml
name: CI Pipeline

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm install
      - run: npm test

This workflow triggers on every push to main or develop, and on every PR targeting main. It checks out the code, installs Node.js 20, installs dependencies, and runs the test suite. If any step fails, the whole workflow fails.

BEST PRACTICES

CI rules your team must follow

Do This

Good CI Habits

  • Commit early, commit often — small incremental changes
  • Never push to main directly; always use PRs
  • Keep the build fast — aim for under 10 minutes
  • Fix broken builds immediately — it's the #1 priority
  • Write tests for every new feature (no tests = no merge)
Avoid This

CI Anti-Patterns

  • "Works on my machine" — CI catches environment-specific bugs
  • Long-running feature branches (more than 2-3 days) cause painful merges
  • Ignoring flaky tests — they erode trust in the entire pipeline
  • Skipping CI checks for "quick fixes" — that's how production breaks
WRAP-UP

Summary & what's next

Lecture 10 · Key takeaways

What you should remember

  • 4 DevOps Principles: Systems Thinking, Feedback Loops, Experimentation, Automate Everything
  • SVN vs Git: Centralized vs Distributed; Git wins with speed, offline work, cheap branches
  • Git ≠ GitHub: Git is the engine, GitHub adds collaboration, PRs, and CI/CD
  • Gitflow: main, develop, feature/*, release/*, hotfix/* — each with a clear purpose
  • CI with GitHub Actions: YAML workflows triggered on push/PR; Workflow → Job → Step
Next lecture · Lecture 11

Tue, 30 Jun 2026 · 12:00–13:00 · Unit IV

Infrastructure as Code; Continuous Delivery & Deployment; Continuous Monitoring; Jenkins Pipeline.

Before next class

Quick prep

Create a free GitHub account (if you don't have one) and explore the Actions tab in any public repository.

CSDV3017 · DEVOPS
SHEET 01/14